1. Field of the Invention
This invention relates generally to wireless and long distance carriers, Internet Service Providers (ISPs), and information content delivery services/providers and long distance carriers. More particularly, it relates to location services for the wireless industry.
2. Background of Related Art
Location information regarding subscribers is becoming increasingly available in a wireless network. Location information relates to absolute coordinates of a wireless device.
FIG. 4 shows a conventional LoCation Services (LCS) request.
In particular, as shown in FIG. 4, a location server 106 requests location information regarding a particular mobile subscriber (MS) from a core network node, e.g., from a Mobile Switch Center (MSC) 110. Requested information regarding a particular wireless device (MS) may include, e.g., attach, detach, and location area update. The location server 106 may also request information regarding the wireless device such as attach, detach and/or location area update from a Packet Data Node (e.g., SGSN, GGSN, or PDSN), or help the device calculate x/y direction. Typically, location information regarding a particular wireless device is requested of a home location register (HLR).
As shown in step 1 of FIG. 4, a locations services client 104 sends a message to a location server 106.
In step 2, the location server 106 sends a Provide Subscriber Info message to a Home Location Register 108, requesting subscriber information regarding a particular subscriber.
In step 3, the carrier's Home Location Register (HLR) 108 provides the subscriber information for the requested subscriber back to the location server 106.
In step 4, location information regarding the requested subscriber is requested to either an MSC or Packet Data node 110. The MSC or Packet Data Node preferably provides precise location information using, e.g., a global positioning satellite (GPS), triangulation techniques, or other relevant locating technology, or helps the device calculate X/Y direction.
In step 5, the location request is forwarded to the Radio Access Network (RAN) 112 if needed.
In step 6, precise, updated location information regarding the requested subscriber is sent to the location server (LS) 106.
In step 7, an ultimate response to the original location request is sent to the LCS client 104 that initially requested the location information.
Secure User Plane for Location (SUPL) is a standards-based protocol that has been developed to allow a mobile handset client to communicate with a location server, e.g., as shown in step 1 of FIG. 4. The SUPL specification is defined by the Open Mobile Alliance (OMA) standards working group. Refer to OMA Secure User Plane Location Architecture document, OMA-AD-SUPL-V1—0-20060127-C for more details on OMA SUPL call flows; and OMA User Plane Location Protocol document, OMA-TS-ULP-V1—0-20060127-C. The OMA SUPL Version 1 specifies two basic types call flows: (1) a SUPL network initiated (NI) call flow, and (2) a SUPL set initiated (SI) call flow. According to the SUPL standard, a session ID has a unique value consisting of server and handset portions.
FIG. 5 shows typical OMA mobile terminated call flow for a SUPL location request initiated by a SUPL agent.
In particular, as shown in FIG. 5, messages are passed between a SUPL agent 802 residing in the network, a sat reference server 804, a SUPL server 806, a PPG 808, and a SUPL terminal (SET) 812.
The SUPL server (or SUPL location platform (SLP)) 806 comprises a SUPL location center (SLC) and SUPL positioning center (SPC). A mobile device is generalized in FIG. 5 as a SUPL enabled terminal (SET) 812. The SLC coordinates operations of SUPL communications in the network, and controls the SPC component. The SPC Provides global positioning system (GPS) assistance data to the SUPL enabled terminal (SET) 812, and performs precise position calculation of a SET 812.
Network initiated location requests 820 arrive at the SUPL server 806 via an MLP interface. The SUPL server 806 processing this network initiated request is required to send a trigger message (SUPL INIT message) 822 to the SET 812 for validating and initiating a SUPL positioning session 828. The trigger message 822 is sent to the SET 812 as a push message 824 from the PPG 808 (or as an SMS message from an SMSC/MC). At that point, the SET 812 needs to establish a secure TCP/IP connection to the SUPL server 806 to respond to the SUPL positioning request.
For network initiated end-to-end IP based location services, when a location server needs to find out contact information (e.g. an IP address) of a given target, the location server sends a trigger to the target to allow the target to establish a session with the location server. Conventional IP based user plane location services (e.g., OMA SUPL) are built upon WAP Push/SMS messaging and TCP as a transport protocol for initiating a mobile terminating positioning procedure.
There are some scenarios where conventional use of User Plane Location Services does not work or does not work well.
For example, in one scenario where a target device has Internet access via, e.g. WLAN, LAN, or DSL, it may not be possible for the location server to initiate location by use of an SMS, WAP Push. This is particularly true if the location server cannot determine the IP address of the target device, and the network to which the target device attaches does not support correct inter-working with SMS or WAP Push messaging.
A second example relates to Voice over IP (VoIP) based emergency calling (there are some variances in the wireless industry, e.g., IMS emergency in the 3GPP standard and MMD emergency in the 3GPP2 standard, referred to generally as a SIP call by the IETF.) This scenario depicts an emergency call which has already established a SIP session with the serving network. During the emergency call, the appropriate Public Safety Answering Point (PSAP) may require updated location information relating to the emergency caller.
The present inventors appreciate that the existing mechanism of using WAP Push/SMS messaging may not be efficient and reliable, as WAP Push/SMS messaging is built upon store-and-forward mechanisms. In other words, there is no guarantee that the trigger of a location service request will be delivered to a target before the emergency call ends.